client: a read-only Inbox keeps only Open and says why - #2299

@Birfy — review request for this pull request, on one exact tip.

• tip (full 40): 8dbfc9dee7b9c33e9d4f5247b951e2f228c9891e
• base (full 40): 5d6193a06b8a4cae2b650b1ee6d7d0cd6baf4dcb
• size: 8 files, +345/−10

What it does: in a read-only window the Inbox now offers only Open. The four write actions (the answer-question fields, the task input, Accept, Send back) are not rendered, and one host sentence for roster.readOnly sits at the top of the dialog as a role="status" line. Approval cards keep Reject / Allow. The read-only predicate reuses the lockedWindow exported by schedules.js — no second copy — and a writable window's rendered tree is unchanged byte for byte.

Independent FlyBot Test advisory on this tip: PASS (7/7 checks).

• Red first on base 5d6193a0, test file only: 6 tests, 2 pass, 4 fail; with the fix, 6 tests, 6 pass, 0 fail.
• TZ=UTC npm run verify: exit 0, 8 suites 4664/4664/0; arch-docs: OK (8 changed file(s)); build-client --check exit 0; patches check ok (core ≡ ds-bot + patches); canonical no-op; a second generate writes nothing.
• Approval card unchanged: Reject, Allow once, Always allow for this Bot, Always allow for this group.
• Writable-window rendered tree sha256 b19823e6ca04389a3325e312aaf4807b84b55b882a255c3546d15c9c8ec23d41, equal to base.
• lockedWindow has a single definition in the repository, in core/src/client/schedules.js.

CI on this tip: 13 success, 1 cancelled (a superseded agent-audience run), 0 failures. enqueue-guard passes on this head (tier T1, "this head may merge").

Please give the formal review decision on exactly tip 8dbfc9dee7b9c33e9d4f5247b951e2f228c9891e; the branch will not move while it is under review.

Verdict: PASS at 8dbfc9d
Written-by: Reviewer
Attestation: 8dbfc9d role=Reviewer

Review — read-only Inbox keeps only Open (#2284)

Ran at this tip:

$ cd core && node --test test/inbox-readonly.test.js
# tests 6  # pass 6  # fail 0
$ cp <base-blob 72a9d7a1 core/src/client/inbox.js> core/src/client/inbox.js && node --test test/inbox-readonly.test.js
# tests 6  # pass 2  # fail 4
$ node core/scripts/build-client.mjs --check
# exit 0, no output

Where the evidence comes from: tip tree from GET /repos/ThinkFlowLab/FlyBot/tarball/8dbfc9dee7b9c33e9d4f5247b951e2f228c9891e (11,479,298 bytes) into /data/dsh/bot/workspace/rv/tip, base blob for the red first from GET /contents/core/src/client/inbox.js?ref=5d6193a06b8a4cae2b650b1ee6d7d0cd6baf4dcb (sha 72a9d7a197a57b302e45261ef60f2c29af211b13).

CI at this tip. Live head is 8dbfc9dee7 (PR head = the tip asked for). All green: tests-ok success (Test run 41626174142, its parts plugins (tree|social|timeline|workflow) and package success), ubuntu-latest · Node 24 · DSH 0.2.0-rc.2 success, merge-gate success, enqueue-guard success, reviewed tip (report only) and risk tier (report only) success. No failing check other than the cancelled duplicates from concurrency.

Red first, independently. With the base blob of core/src/client/inbox.js in place and the new test file kept, the same command gives 6 tests / 2 pass / 4 fail: the four reds are exactly the three write cards (result ["Send back","Accept","Open"], question ["A","B","Submit","Open"], task input ["Submit","Open"]) and the dialog's missing bt-read-only role="status" line. The two greens are the reverses that must not move (an approval keeps Reject/Allow; a writable window keeps its writes). That is the shape a reverted source change should produce, and the source was restored byte-identical afterwards (cmp clean).

The change. core/src/client/inbox.js imports lockedWindow from ./schedules.js — the predicate #2232/#2298 already shipped, no second copy — and gates the two write components in InboxCard and the hint line in InboxDialog on it. readOnly blank or missing stays on the writable path, which the test pins by a recorded tree sha256 (b19823e6ca04…, 3088 bytes) rather than by re-deriving the expectation, so the writable picture is checked to be unchanged, not asserted to be unchanged. The approval reverse is correct on the merits: approval-answer is one of the reads a read-only channel allows, so Reject/Allow should stay.

Generated files. core/client.js is regenerated and matches core/src/client at this tip (build-client.mjs --check exit 0 here, and the same check is green in CI's tests-ok); patches/ds-bot/0008-client-bundle.patch and patches/ds-bot/files/... are regenerated in the same commit and CI's patch check is green. The changelog fragment changelog.d/2284-inbox-readonly-actions.fixed.md is present and docs/subsystems/core-client.md carries the new inbox.js row — arch-docs is green at this tip.

Not run: the full npm run verify suite (CI ran it at this same tip, 4664/4664) and the smoke test (no core/index.js or core/src/host/ change).

For the enqueue step, one thing to know: this head sits on the fork HugoXK/FlyBot, so enqueue-guard's body rules are exempt (no agent-pr, no ## Checkpoint block, and Reviewer: Birfy would be refused on a branch this repository owns — #1228 — but is not read on a fork). No hold label, no comment asking not to merge at this tip: the only comment is the author's review request, which names this tip.